前言

昨天我們有看到django中有個MigrationGraph，接續前面的部分應該就會看到graph的真面目了！這也是我第一次在程式中看到資料結構/演算法的應用～想想就覺得興奮！

正題

那我們昨天的位置到了django.db.backends.base.base.BaseDatabaseWrapper中的_cursor()

而今天要從下面的

看看他究竟return了什麼～

裡面的function是在子類別的DatabaseWrapper覆寫，而connection呢就是我們昨天跟sqlite3 dbapi2溝通產生的，這邊還有一個factory參數SQLiteCursorWrapper

這個class是照著sqlite3 dbapi2的規範去覆寫，看起來是要處理字串
接著是_prepare_cursor()

平常開發都用debug模式，就看看debug吧

看起來是會把所有跟database的指令都記錄到log裡面
到目前為止就是大致的（django.db.migrations.recorder.MigrationRecorder中的has_table()）

過程
接著往下看會去拿取資料庫的table name

當中的introspection.table_names()可以在DatabaseIntrospection中找到

再往裡面看get_table_list()

哦！終於是看到SQL語法了
最後會確認Migration是否存在database的table裡面


ORM相關的部分我們之後再看看
上面MigrationRecorder的部分就這樣告一個段落
接下來我們回到loader這邊


註解大概解釋了，graph中存的data以及運作流程
接著往下

這邊就會根據我們實際存在app中的migrations資料夾內的檔案組成graph，並且確認他們之間的依賴性，並也加進graph中

都建好graph後要確認其consistency

最後面要確認是否有循環


到這邊，我們MigrationLoader的init終於結束了
明天再回到MigrationExecutor吧！

結語

migrate真的是很龐大，要跟一堆物件做比對確認後才會真的寫進資料庫（這邊都還在前面的階段而已），有點好奇這樣的做法和想法是怎麼孕育且迭代出來的！！

本日重點

• 產出cursor的後半段
• migrations中的files都會被變成graph